x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL

x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL

The undefined behaviour sanitiser shows that it really is NULL via the
pre_initcall path.

  (XEN) ================================================================================
  (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66
  (XEN) member access within null pointer of type 'struct processor_pminfo'
  (XEN) ----[ Xen-4.8-unstable  x86_64  debug=y  Not tainted ]----
  <snip>
  (XEN)    [<ffff82d0801c4231>] cpufreq_add_cpu+0x161/0xdc0
  (XEN)    [<ffff82d0801c6610>] cpufreq.c#cpu_callback+0x20/0x30
  (XEN)    [<ffff82d0804eefad>] cpufreq.c#cpufreq_presmp_init+0x2d/0x50
  (XEN)    [<ffff82d0804c5942>] do_presmp_initcalls+0x22/0x30
  (XEN)    [<ffff82d08051852d>] __start_xen+0x378d/0x42f0
  (XEN)    [<ffff82d080100073>] __high_start+0x53/0x60

Fix two other occurances of the same buggy logic.

The processor_pminfo[] objects are only allocated as a result of
XENPF_set_processor_pminfo hypercalls, which means that this early cpu
callback will always hit the early NULL check, and is therefore pointless.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>